Skip to content

Add IoT Metrics Support #710

Merged
xiazhvera merged 32 commits intomainfrom
iot_metrics_2
Apr 6, 2026
Merged

Add IoT Metrics Support #710
xiazhvera merged 32 commits intomainfrom
iot_metrics_2

Conversation

@xiazhvera
Copy link
Copy Markdown
Contributor

@xiazhvera xiazhvera commented Dec 23, 2025

Issue #, if available:

Description of changes:

  • Bind IoTDeviceSDKMetrics and metrics related features , CRT is now appending AWS metrics by default.
  • Add enableMetrics option to allow user disable metrics.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Comment thread source/mqtt_client_connection.c Outdated
Comment thread awscrt/mqtt5.py
Comment thread awscrt/mqtt.py Outdated
from awscrt.io import ClientBootstrap, ClientTlsContext, SocketOptions
from dataclasses import dataclass
from awscrt.mqtt5 import Client as Mqtt5Client
from awscrt.mqtt5 import Client as Mqtt5Client, SdkMetrics
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of pulling SdkMetrics in from mqtt5, should we instead implement an mqtt3 version of SdkMetrics? It appears there's precedence for this with the double implementation of OperationStatisticsData. Unsure if this is a good or bad practice but it's one we've previously used. This could also potentially allow us to set different things by default for mqtt3 vs. mqtt5 or it could add confusion and a second place to update things when we make changes...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer not to duplicate the structure across MQTT3 and MQTT5. Maintaining it in two places increases the risk of them going out of sync over time. I realize that's the pattern we used in Python, but I wouldn't consider it a good practice to follow.

If we ever need different defaults for MQTT3 vs. MQTT5, we can always inherit from the base structure at that point.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could add a separate module, like we did with req-resp client. With meta data implemented, the metrics functionality should be big enough to be in its own module.

Comment thread awscrt/mqtt.py Outdated
Comment thread awscrt/mqtt5.py Outdated
Comment thread awscrt/mqtt5.py Outdated
Comment thread source/mqtt5_client.c Outdated
Comment thread awscrt/mqtt.py Outdated
Comment thread source/mqtt_client_connection.c Outdated
Comment thread source/mqtt5_client.c
Comment thread awscrt/mqtt5.py
Copy link
Copy Markdown
Contributor

@sbSteveK sbSteveK left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems solid. It looks like MQTT3 and MQTT5 will have to go through different binding paths when metrics is expanded. Would be ideal to use the same for both but unsure if that's possible without changes underneath?

@xiazhvera
Copy link
Copy Markdown
Contributor Author

Seems solid. It looks like MQTT3 and MQTT5 will have to go through different binding paths when metrics is expanded. Would be ideal to use the same for both but unsure if that's possible without changes underneath?

Unfortunately, I don't think we can change the binding path for MQTT3 and MQTT5 without changes underneath...

@xiazhvera xiazhvera merged commit 4173141 into main Apr 6, 2026
77 checks passed
@xiazhvera xiazhvera deleted the iot_metrics_2 branch April 6, 2026 21:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants